[Previous] [Next] [Index]
[Thread]
Re: Hidden Agenda
Nick,
>
> Mark Linehan:
>
> > "most US people do not realize that for a payment system to
> > make it it must be exportable."
>
> Perhaps because they realize that it can also be written
> overseas and imported, avoiding silly restrictions.
I (we?) completely agree the restrictions, esp. on sw, are stupid. But they
exist. For us it's a big problem, believe me, we want to manufacture the stuff
(and we cannot just do it overseas, btw, the NSA do not allow this). It's not
just our problem; essentially it's a big plus for everybody if US companies can
produce this code - which would be fine for iKP _with_ STRONG security.
>
> >[iKP approved by NSA]
>
> A great marketing advantage outside the U.S., no doubt!
This is not marketing related - just enables us (and others) to export, as well
as (hopefully...) to import to some places (eg France) where even importing
crypto is difficult.
Now you may have ment that this is a _disadvantage_ abroad... Why? iKP does
provide STRONG security (just not general purpose encryption - iKP is just
a payment protocol, not replaces ssl/shttp/other security mechanism)
>
> BTW, do we get to see the iKP source code, or does the NSA
> also frown on our ability to verify the abscence of back doors
> in U.S. software?
Why, I have every hope that we'll have several public domain implementations
of iKP, as well as different vendors offering it. Of course the NSA does
inspect final products (to see we didn't cheat _them_ and put strong general
purpose crypto).
We do not like it but exportability is an important concern. It's not just
us who decide this, it's also the financial organizations. Even if some people
don't care, everybody should agree that a standard should not ignore a big
part of the community. So let's move forward to discuss technical details,
missing/surplus requirements, additional details, etc. etc....
Best, Amir
p.s. discussion of iKP is mostly on e-payment@cc.bellcore.com
References: